IBIS Macromodel Task Group Meeting date: 10 Apr 2012 Members (asterisk for those attending): Agilent: Fangyi Rao * Radek Biernacki Altera: David Banas Ansys: Samuel Mertens * Dan Dvorscak * Curtis Clark Arrow Electronics: Ian Dodd Cadence Design Systems: Terry Jernberg * Ambrish Varma * Feras Al-Hawari Celsionix: Kellee Crisafulli Cisco Systems: Ashwin Vasudevan Syed Huq Ericsson: Anders Ekholm IBM: * Greg Edlund Intel: Michael Mirmak LSI Logic: Wenyi Jin Maxim Integrated Products: * Mahbubul Bari Mentor Graphics: * John Angulo Zhen Mu * Arpad Muranyi Vladimir Dmitriev-Zdorov Micron Technology: Randy Wolff NetLogic Microsystems: Ryan Couts Nokia-Siemens Networks: * Eckhard Lenski QLogic Corp. * James Zhou Sigrity: Brad Brim Kumar Keshavan * Ken Willis SiSoft: * Walter Katz Todd Westerhoff Doug Burns Mike LaBonte Snowbush IP: Marcus Van Ierssel ST Micro: Syed Sadeghi Teraspeed Consulting Group: Scott McMorrow * Bob Ross TI: Casey Morrison Alfred Chong Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla The meeting was lead by Arpad Muranyi ------------------------------------------------------------------------ Opens: -------------------------- Call for patent disclosure: - None ------------- Review of ARs: - Arpad to propose IBIS spec changes to clarify ISS D2A & A2D interfaces - no update - Arpad to write a new revision of BIRD 117 and 118 to generalize references to parameters in files (.ami or any) - in progress on 117 Ambrish update BIRD 145 for pad to pin mapping and other clarifications - in progress ------------- New Discussion: BIRD 144 discussion: - Arpad: Last week we ended the meeting while discussing BIRD 144.3. - Is this BIRD simplifying things? - Boundary conditions were added. Did they make it too complicated? - Are people ready to continue discussion of these questions? - Ambrish: (summarizing the development path of the BIRD) - Propose removing the new boundary conditions from the BIRD. - Replace with a description of assumptions in certain cases. - Will better serve the BIRD's goal of simplicity. - Feras: Goal is ease of use. - Point to a Touchstone file directly. - Portable since you don't need any SPICE syntax wrapper. - Termination was added at this committee's request. - Instead, we might simply specify the EDA tool's expected behavior. - Arpad: Define a general rule in the spec instead of rules for each model. - Ambrish: User can still use another wrapper for more complex cases. - Feras: Yes, [External Circuit] can easily handle a more complex case. - It could cascade to another [External Circuit] for termination. - Termination only an issue for [External Model]. - However, a termination scheme was proposed and it's not too complex. - Arpad: Two questions for general rules: - 1. Are reserved terminals connected directly to S-parameter blocks? - 2. What to do if S-parameter has extra ports (dangling ports)? - Feras: Direct connection between reserved terminals and Touchstone ports. - floating ports -> high impedance. - Radek: Port is two terminals. How is a port defined in this context? - Feras: SPICE subcircuit has terminals, S-parameters have no such concept. - Radek: Yes, an S-parameter port is + and - terminals. - How is this defined in this BIRD? - Arpad: Good point, IBIS is sometimes loose on this point of Ground ref. - Radek: We follow HSPICE convention, but it's well defined. - What is the reference node here? - Feras: Ground is the common reference node. - Radek: You must state this explicitly. - Arpad: IBIS has [Pulldown Reference] defined, not simply ground. - but there is a reserved analog "Port Name", A_gnd for analog ground in the [External ***] section of IBIS which could be used for this. - Feras: DC voltages might be entirely inside the model. - Only 2 terminals for an S1, for example. - Only 4 terminals for a differential buffer. - 7 basic terminals in IBIS, among them are the 4 pwr/gnd refs. - James: by definition S-parameters have no global ground. - not a valid concept for S-parameters. - Arpad: True. - but that doesn't prevent user from connecting all refs to same point. - Feras: BIRD currently assumes global ground is the common reference. - James: We can define how terminals are connected if not to S-parameters. - But, it would not affect the S-parameter block in any way. - Feras: True. - James: IBIS only provides framework/format. User can decide. - Feras: BIRD now gives extra flexibility, but tradeoff is complexity. - Ex. Simple general rule - any dangling terminal gets high impedance. - James: So the BIRD gives a default behavior but with flexibility? - Ambrish: No, one or the other. - Arpad: If you stick an S-param block in a normal [External Model], - Direct connections to reserved terminals, others dangling. - [External Circuit] case is more flexible. - It could use another [External Circuit] wrapper for termination. - Burden for termination is on the model maker. - Walter: Everything in this BIRD could be done with IBIS ISS (BIRD 116). - This discussion is going into a rat hole. - Propose a straw-man vote on whether to continue with this discussion. - Feras: I agree that it can all be done with BIRD 116. - However, this is a shortcut for S-parameter blocks. - Walter: Shortcut is exactly what BIRD 122 proposed. - You rejected BIRD 122 because you didn't want shortcuts. - Feras: My problem with BIRD 122 was with the SPICE templates. - Not as general as S-parameter blocks. - Ambrish: We also had issues with the AMI specific nature of BIRD 122. - Walter: I make a formal motion that we should vote on this. - Now or next week. - Ambrish: We have support for this BIRD from other users and EDA vendors. - Feras: I agree with Walter. Let's decide on how to proceed now. - Arpad: Do we have a second to Walter's motion. (silence) - I think we should move on to other topics, so I will second the motion. - Radek: I don't support voting today. - We should make sure everyone knows we will be taking a vote. - We should have a vote to show our group's opinion to the Open Forum. - Arpad: I will send a notification of the upcoming vote to the reflector. AR: Arpad send notification of upcoming vote to the reflector. ------------------ CTLE example email: - Arpad: Walter, do you have anything to discuss? - Arpad: (highlighting April 4th CTLE email on screen) - Walter: Example in the current spec only has one set of poles and zeros. - New example with 2 sets of poles and zeros. - A two row table for poles. - The first row has three poles. - Second row has two poles, but since N/A isn't available 0,0 for third. - Arpad: Could we have some background? Why? - Walter: Existing example only allowed one transfer function. - wanted to provide an example to define multiple. - Feras: This is frequency domain. We usually work in time domain for this. - Walter: All vendors describe their CTLEs with poles and zeros. - Feras: The model consumes these values? - Walter: The model uses them in Init(), GetWave(), etc. - Radek: Is this just a selector, or could the user modify values? - Could just use hard coded values inside the model and a pure selector. - Walter: The model maker could choose to do either. - Arpad: The entire table is passed into the model? - The selector is then used to choose? - Radek: (0,0) is a valid pole at the origin. It shouldn't mean no pole. - (0,0) for pole and zero would be okay as a nothing. - Walter: I would certainly prefer to say N/A, but it's not allowed. - Ambrish: Where is the original example? - Bob: It's a Table format example. - James: This is a model specific parameter, the meaning could be anything. - Ambrish: yes. - James: Radek's question was about specific data. - Spec shouldn't assign any meaning to data in a model specific param. - Bob: data must be consistent with what the .dll wants. - James: yes, but the spec should not define any model specific data. - Bob: yes, as long as the data is formatted correctly. - Ambrish: This looks more like a CTLE example than a Table example. - Bob: model specific parameter is vendor specific. - Could define any convention for this data. - (0,0) could be okay as do-not-use. - Or, for example, a positive pole could mean do-not-use. - James: the tool need not understand this specific data. - Arpad: yes, model specific implies what you just said. - Bob: complex conjugate pairs are implied by this example. - Arpad: So what? It's model specific. - Feras: I agree, for physical systems we expect complex conjugate pairs. - Arpad: That doesn't matter for this example. - James: Agree, specification should not attempt to provide meaning. - Radek: I have a question of a different sort. - We have unfinished discussions on Out and InOut for model specific. - Therefore, I think we should not use InOut in this example. - Keep this example strictly In, until we can clarify InOut and Out. - Ambrish: We have InOut in a BIRD. - Walter: I have no objection to using In for this example. - Would provide a nice segue to InOut for the Rx case though. - Radek: yes, I understand your point 100 percent. - Feras: I would prefer the example list the conjugates. - Walter: None of the standards do it that way. - Arpad: I want to get back to Radek's (0,0) question. - Do we have a limitation we need to address? - Is the fixed row length requirement a problem without N/A? - Do we need a spec change? - Walter: If CTLE were a reserved parameter, we'd have to address it. - Arpad: We don't need to address it here? - Radek: Just don't say it here. - Since it's model specific, just don't provide the description. - Bob: It's an application specific example. - Arpad: Do we need to address a limitation and future problem? - Bob: If we address it, I prefer another column entry instead of N/A. - Another column entry could define the length of the row. - Preferable to polluting syntax with N/A symbols. - Ambrish: I would want an example of the param string itself. - Arpad: Okay, any requests for this AR for Walter? - 1. InOut -> In - Ambrish: - 2. Text explaining what the example does. - 3. Show the parameter string. - Radek: It is clear already. - These rules are already in the Table BIRD (BIRD132). - Ambrish: Examples in BIRD 132 all describe the param string. - Arpad: Okay, I get it. (make it consistent with other examples) - Arpad: (Final summary of the three items in the AR.) - Ambrish: okay. - Arpad: Walter, can you and Bob do it. - Walter/Bob: yes, no problem. AR: Walter/Bob prepare CTLE parameter string example ------------- Next meeting: 17 Apr 2012 12:00pm PT Next agenda: 1) Task list item discussions ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives